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Background of the Invention 

1. Field of the Invention , 

This invention is directed to an interactive computer request processing system. 
More particularly, the invention relates to the field of refilling patient prescriptions using 
telephone and computer equipment even if patient databank computer interactive 
communications are unavailable. 

2. Background Art, 

Patients require health care services, such as prescription refills, from health care 
service provider organizations, such as pharmacies. These organizations often provide 
automated services to their patients to increase efficiency. Consequently, automated 
pharmacy technologies must be developed and advanced to provide such services. The 
resulting technology has become increasingly complex. Multiple layers of automated 
computer equipment are being placed between a patient and the health care provider's 
service. Therefore, multiple points of failure in such technology exist. Any point of failure 
can cause an automated system, such as an automated pharmacy prescription refill system, 



to be unavailable for use by a patient demanding the service if some component of the 
automated system has failed. 

Existing automated pharmacy refill systems utilize an answering device to interact 
with a databank. The databank contains specific patient information including the status of 
prescriptions. A difficulty with such systems is that if the databank is unavailable to the 
answering device, the answering device is unable to perform prescription inquiries for the 
patient until such time as communication with the databank is re-established. If the patient 
databank computer's interactive communications are unavailable to the answering computer, 
the answering computer cannot perform prescription inquiries on demand for the patients 
since it requires interactive communication with the patient databank computer. Typically, 
when encountering this situation, callers are informed that services are unavailable. A caller 
must, therefore, end the call without being provided the needed service. 



Summary of the Invention 

Consequently, the primary objective of this invention is to allow a patient to request 
prescription refills on a client computer or answering computer regardless of whether 
interactive communications are possible with the patient databank computer. Interactive 
5 communications with the patient databank computer typically perform prescription refill 
inquiries and subsequent interpretation of an inquiry response. If the patient databank 
computer is unavailable, the client or answering computer accepts and stores patient refill 
requests until interactive communications with the patient databank computer are available. 
When interactive communications are re-established, the client computer retrieves refill 
Qlo requests from the local database and transmits inquiries to the patient databank computer 
for validation. The host computer checks each refill request to determine if the refill 
f!" request is vaUd, i.e., if it is valid to refill the prescription. If the prescription is still active, 

i the last fill date, the days supply and the grace period are used to determine when the 

prescription can be filled. 
Nib The invention presented herein is a means for allowing patients to request their 

prescription refills on demand even if the patient databank computer is unavailable for 
interactive communications wdth the client computer at the moment in time when the 
inquiry needs to be made. The invention consists of specific computer programming 
software algorithms and techniques, and also specific defined procedures performed by 
20 computer operators, which operate on a general purpose computer engineered and 
programmed for answering incoming telephone calls and performing pharmacy prescription 
refill processing. 
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More particularly, the invention enables patients using an ordinary telephone to place 
a telephone call that is answered by a client computer. The client computer collects from 
the calling patient specific information necessary to refill the patient's prescription, 
preferably by touch-tone input from the patient's phone. The client computer has 
interactive communications with a patient databank computer that contains specific patient 
information including the status of prescriptions. The client computer, using the collected 
patient information, queries the patient databank computer. The patient databank computer 
then returns a response with particular information about the patient's prescription. The 
information is then interpreted and the client computer informs the patient whether or not 
the prescription can be refilled. However, if the interactive communications link with the 
patient databank computer is unavailable, then the client computer collects the calling 
patient's specific information for future validation processing. The client computer then 
informs the patient that if the prescription refill is valid, the prescription will be available 
to the patient at some point in time. 

In one embodiment of the invention, the client computer notifies the patient of the 
patient's refill status once interactive communications with the host computer have been re- 
estabhshed and the patient's request has been validated. In the notification step, the client 
computer extracts the telephone number and status associated with the request and attempts 
to contact the patient. The client computer then states whether the call was delivered for 
later reporting to an operator. 
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Brief Description of the Drawings 
Fig. 1 depicts the on-hne pharmacy automated refill system of the present invention. 
Fig, 2 is a flow diagram depicting the off-line communications configuration of the 
client computer. 

Figs. 3a and 3b are flow diagrams depicting the on-line communications 
configuration of the client computer. 

Fig. 4 is a flow diagram depicting the on-line communications configuration of the 
client computer with operator initiated validation processing. 

Figs. 5a, 5b, 5c, 5d and 5e are flow diagrams depicting the on-line communications 
configuration of the client computer with automatic validation and notification processing. 

Figs. 6a and 6b are flow diagrams depicting the on-line or off-line communications 
configuration of the client computer with manual notification processing. 

Figs. 7a and 7b are summaries of the program used by the client computer when 
configured for on-line communications. 

Fig. 8 is a summary of the program used by the client computer when configured for 
off-line communications. 

Figs. 9a, 9b, 9c and 9d are summaries of the program used by the client computer 
when configured for on-line communications with automatic validation and notification 
processing. 



Detailed Description of the Preferred Embodiments 

Before explaining the invention in detail, it is to be understood that the invention is 
not limited in its application to the specific details of the implementation of the software 
as used for automated prescription refill systems outlined in the following descriptions and 
charts. The invention is capable of other embodiments and of being practiced or carried out 
in many ways. It is understood that the phraseology and terminology employed herein is 
for the purpose of description and not limitation. 

Referring to Fig. 1, the answering computer or client computer 10 is designed to 
answer incoming telephone calls from patient telephone 12 and accept information from 
ClO patients. Client computer 10 uses a complex software program that executes during normal 
operations. The information is stored in data storage 14 for use in processing prescription 
refill requests. The patient databank computer or host computer 16 contains patient 
databank 18, which contains specific patient information, including the patient's prescription 
information. Client computer 10 and host computer 16 are interconnected using one or 
*'^|l5 more communications links 20 that support interactive communications between the 
computers. Examples of communication links 20 that may be used include serial 
connections such as VTlOOs and VT320s for connecting a dumb terminal to a mainframe, 
but other means, such as LAN connections, may be used to communicate with host 
computer 16. It is noted that processes performed by client computer 10 are in theory 
2 0 parallel processes and not serial processes in spite of computer operating system functional 
limitations. 
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Interactive communications between client computer 10 and host computer 16 consist 
of defined messages that are sent and received between the computers. In general, client 
computer 10 sends a message (initiates a transaction) to host computer 16 and host 
computer 16 sends a message (completes a transaction) back to client computer 10. The 
sending and receiving of a defined set of messages will be referred to as a transaction. A 
transaction is initiated by client computer 10 which sends a defined initiator message to host 
computer 16. Host computer 16 responds predictably with respect to the particular initiator 
message by sending a defined response message back to client computer 10, thus completing 
the transaction. 

In practice, client computer 10 preferably uses a specific initiator message to test the 
current interactive communications status with host computer 16 and also a specific initiator 
message to make prescription refill request inquiries. Host computer 16 sends specific 
response messages with respect to the specific initiator messages back to client computer 10 
so that appropriate actions can be taken, such as informing the calling patient of his or her 
prescription status. If no response message is received by client computer 10 after an 
initiator message has been sent, interactive communications between host computer 16 and 
client computer 10 have been interrupted. Additionally, if a "hardware status" such as a 
phone dial tone or other "hardware status" has been interrupted, then interactive 
communications between host computer 16 and client computer 10 have been interrupted. 
Client computer 10 will then assume that interactive communications are not available. 
Therefore, any attempts by client computer 10 to initiate a transaction with host computer 



16 to determine if host computer 16 will respond appropriately for re-establishing interactive 
communications will be automatically suspended. 

Interactive communications between client computer 10 and host computer 16 can 
be activated (on-line mode) or deactivated (off-line mode) by either client computer 10 or 
host computer 16. 

When client computer 10 engages in interactive communications with host computer 
16, client computer 10 is considered to be on-line with host computer 16. Conversely, when 
there is no interactive communication, client computer 10 is considered to be off-line from 
host computer 16. 

An automated prescription refill system consists primarily of client computer 10 and 
host computer 16. Client computer 10 answers incoming telephone lines and interacts with 
patients over the telephone. Host computer 16 contains the patient information databank 
or patient database 18 and provides practically instantaneous information to client computer 
10 using one or more interactive communication links that support the interactive 
communications, which consist of specific transactions. Client computer 10 possesses 
automated refill system software, known in the art, that causes client computer 10 to answer 
incoming telephone lines, interact with patients over the telephone to collect specific 
information, and manage interactive communications with host computer 16. 

For interactive communications to occur between client computer 10 and host 
computer 16, host computer 16 must be operational and permit client computer 10 access. 
Client computer 10 does not control the on-line or off-line interactive communications 
capabilities of host computer 16, but can determine if interactive communications are on-line 
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or off-line. In practice, the interactive communications capabilities of host computer 16 may 
not be available to client computer 10 for a variety of reasons. For example, a system 
operator of host computer 16 may be performing maintenance work, electrical storms may 
be disrupting communications links, power failures may occur, etc. During such times, client 
computer 10 has the capability to operate autonomously without interactive communications 
with host computer 16 by storing patient data such as patient identification numbers and 
prescription numbers. The patient is thus informed of the unvalidated refill request status. 

In one embodiment, after communications have been re-established between client 
computer 10 and host computer 16 and a prescription request has been validated, client 
computer 10 performs a notification telephone call to the patient to inform the patient of 
the request status. 

It is noted that, for the purposes of this application, "operator" is any entity capable 
of issuing a command, including humans, software processes, hardware processes, and other 
means. 

Client computer 10 can automatically detect interactive communications loss (off-line 
detection) with host computer 16 without human intervention from a computer operator. 
Also, an operator can manually put communications off-line by issuing a command to client 
computer 10. Conversely, the operator can manually put communications on-line by issuing 
a command to client computer 10. 

A software command referred to as the "host off command" can be issued by an 
operator. The "host off command" configures cUent computer 10 to operate with the 
assumption that interactive communications with host computer 16 are unavailable. Client 



computer 10 then functions according to the configuration and does not expect nor require 
interactive communications with host computer 16 to exist. 

A software command referred to as the "host on command" can be issued by an 
operator. The "host on command" configures client computer 10 to operate with the 
assumption that interactive communications with host computer 16 are available. Client 
computer 10 then functions according to the configuration and does expect but does not 
require interactive communications with host computer 16 to exist. 



Referring now to Fig. 2, when client computer 10 is taken off-line from host 
computer 16 by an operator using the "host off command", represented by box 100, client 
computer 10 is configured for off-line communications. The "host off command" executes 
a simple software program that sets configuration files to be read by client computer 10. 
The operator must then execute the software of client computer 10, represented by box 106. 
Client computer 10 uses software to check for incoming telephone calls and perform other 
tasks as represented by boxes 112 and 118. Client computer 10 answers incoming calls, 
represented by box 124, and gives the caller various options for services, represented by box 
130, thereby continuing to collect specific request information from the patient. Examples 
of various options for services include pharmacy hours of operation and location, 
information on medications, numbers to contact in case of questions or an option to transfer 
to a live person. Client computer 10 then determines whether the caller has ended the 
telephone call or made an invalid selection as represented by box 136. If so, client computer 



O perator Specified Off-line Communications Scenario 





10 ends the telephone call as represented by box 172. Otherwise, client computer 10 queries 
whether the caller wants to request a refill, as represented by box 142. The specific request 
information preferably consists of, but is not limited to: a variable length patient 
identification number, represented by box 148; a variable length prescription number, 
5 represented by box 154; and, optionally, a variable length telephone number, credit card 
number or other information. The specific request information is stored locally in data 
storage 14 of cHent computer 10. 

Client computer 10 gives the outward seamless appearance to the patient that the 
refill system is fully operational. This appearance is maintained even though interactive 

a a 

communications between client computer 10 and host computer 16 are not available for 

y 

Si patient refill request inquiry transactions. The request information is stored on local 

l,j database 14 of client computer 10 for future prescription refill validation processing, as 

M 

3 represented by box 160. The caller is then informed of his or her unvahdated status, as 

H@ represented by box 162. "Unvalidated status" means that the prescription request has been 

^^^4-5 accepted pending validation and will be processed if the request is found to be valid during 
validation processing. Prescription refill validation processing with host computer 16 will 
take place when on-line communications become available. After stored unvalidated refill 
requests are processed by either manual or automatic validation processing, refill requests 
determined to be valid are dispensed, whereas refill requests determined to be invalid are 
2 0 not dispensed, but are stored for notification processing. Both valid and invalid refill 
requests are considered to be validated, as opposed to unvalidated, after the validation 
process has been performed. 
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Finally, client computer 10 queries the caller whether the caller has another refill 
request as represented by box 166. If so, client computer 10 will then obtain a new 
prescription number from the client as represented by box 154; otherwise, client computer 
10 ends the telephone call as represented by box 172. 

Operator Specified On-line Communications with 
Off-line Detection Scenario 

Referring now to Fig. 3a, to place client computer 10 on-line, an operator issues the 
"host on command", represented by box 200. The operator must then execute the software 
of client computer 10, represented by box 206. The "host on command" executes a simple 
software program that sets configuration files to be read by client computer 10. Client 
computer 10 checks for incoming telephone calls and performs other tasks as represented 
by boxes 212 and 218. Client computer 10 answers incoming calls, represented by box 224, 
and gives the caller various options for services, represented by box 230, thereby continuing 
to collect specific request information from the patient. 

Client computer 10 determines whether the caller has ended the telephone call or 
made an invalid selection as represented by box 236. If so, client computer 10 ends the 
telephone call as represented by box 272. Otherwise, client computer 10 queries whether 
the caller wants to request a refill as represented by box 242. 

When client computer 10 is on-line with host computer 16 and a patient calls client 
computer 10 and requests a prescription refill, client computer 10 performs off-line detection 
by using a verification transaction, a software method, or by monitoring statuses rendered 
from other communications-related hardware devices, as represented by box 244. The 



verification transaction immediately determines, as represented by box 245, whether 
interactive communications with host computer 16 are available to perform inquiries. 

If interactive communications with host computer 16 are not available at that 
moment, i.e., host computer 16 is off-line, then off-line communications processing is 
initiated, represented by box 246. Once engaged in off-line communications processing, 
client computer 10 collects specific request information from the patient, represented by 
boxes 248 and 254, shown in Fig. 3b. The specific request information preferably consists 
of, but is not limited to: a variable length patient identification number, represented by box 
248; a variable length prescription number, represented by box 254; and, optionally, a 
variable length telephone number, credit card number or other information. Local database 
14 of client computer 10 then stores the caller's request, as represented by box 260, for 
validation processing when on-line communications with host computer 16 are restored. The 
caller is then informed of his or her unvalidated status, as represented by box 262. 
Preferably, client computer 10 informs the caller of the unvalidated refill status with a 
message similar to, "if your prescription request is valid, it will be filled". Finally, client 
computer 10 will query whether the caller has another refill request, as represented by box 
266. If so, client computer 10 will then obtain a new prescription number from the client, 
as represented by box 254. Otherwise, client computer 10 ends the telephone call, as 
represented by box 272. 

If client computer 10 determines, as represented by box 245 shown in Fig. 3a, that 
interactive communications with host computer 16 are available, then on-line 
communications processing is initiated, represented by box 276. Client computer 10 
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functions according to the on-line configuration and thus expects interactive on-line 
communications with host computer 16 to exist. Once engaged in on-line communications 
processing, client computer 10 collects specific request information from the patient, 
represented by boxes 278 and 284 shown in Fig. 3b. Client computer 10 then validates the 
caller's request with the host computer, as represented by box 286. The caller is then 
informed of his or her validated refill request status, as represented by box 287. Finally, 
client computer 10 will query the caller whether the caller has another refill request, as 
represented by box 296. If so, client computer 10 will then obtain a new prescription 
number from the client, as represented by box 284. Otherwise, cHent computer 10 ends the 
telephone call, as represented by box 272. 



Validation Processing 
Validation processing occurs manually or automatically at the discretion of the 
operator. Manual validation processing is performed by software commands issued by the 
operator. Automatic validation processing is performed automatically by a software process 
on client computer 10 when it is configured by the operator for on-line communications and 
automatic validation processing. To determine whether a refill request is valid, client 
computer 10 first determines whether the prescription is still valid. If the prescription is still 
valid, then the last fill date, the days supply and grace period are used to determine when 
the prescription can be filled. Manual and automatic validation processing is discussed in 
detail below. 
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operator Initiated Validation Processing 

When the operator has configured client computer 10 for off-line communications, 
then all requests are stored on client computer 10, as was discussed in reference to Fig. 2, 
wherein the procedure is represented by boxes 100-160. However, in order to perform 
validation processing, on-line communications must be available. Therefore, referring now 
to Fig. 4, the operator must configure the software using the "HOST ON" command for on- 
line communications, represented by box 300. A command referred to as the "VALIDATE 
command" is then issued by the operator, represented by box 314. The VALIDATE 
command utilizes a software program that chent computer 10 executes during normal on- 
line operations, as discussed below. 

The term "normal operations" refers to when client computer 10 is answering calls 
after the operator has either configured the client computer for on-line or off-line 
communications. The term "abnormal operations" refers to when on-line communications 
have been interrupted, off-line detection has occurred, and requests are being stored for 
validation processing. Validation processing is effected either manually using the 
VALIDATE command or automatically by software processes of the software program 
executing on client computer 10 when it is configured for on-line communications and 
configured for automatic validation processing. 

Client computer 10 may be configured for off-line communications by the operator 
using the HOST- OFF command as discussed in reference to box 100, Fig, 2, or may be 
operated with off-line communications as the result of the off-line detection process as 
represented in boxes 245 and 246, in Fig. 3a. 



The client computer may be configured for on-line communications by the operator 
using the HOST-ON command, as represented by box 300 and as discussed in reference to 
box 200, Fig. 3a. The operator may then issue the VALIDATE command as represented 
by box 314 to perform validation processing before executing client computer 10 operations 
as represented by box 306. 

After the "VALIDATE command" is issued by the operator, client computer 10 
determines, as represented by box 396, whether stored requests exist. If no stored requests 
exist, then the operator executes the software of client computer 10, represented by box 306. 

If stored requests do exist, then when client computer 10 is on-line with host 
computer 16, client computer 10 performs off-line detection by using a verification 
transaction, a software method, or by monitoring statuses rendered from other 
communications-related hardware devices, as represented by box 344. The verification 
transaction determines, as represented by box 345, whether interactive communications with 
host computer 16 are available to perform inquiries. 

If on-line communications with host computer 16 are not available, i.e., host 
computer 16 is off-line, then a communications failure between client computer 10 and host 
computer 16 exists. The operator is then notified of the communications failure between 
client computer 10 and host computer 16, as represented by box 347. 

If client computer 10 determines, as represented by box 345, that interactive 
communications with host computer 16 are available, then a refill request inquiry transaction 
is initiated from client computer 10 to host computer 16, as represented by box 388. 

Ghent computer 10 then determines, as represented by box 390, whether the client 



request is a valid request. A request that is validated by host computer 16 is stored on data 
storage 14 of client computer 10 as a valid pending refill request for dispense transaction 
processing, represented by box 392. Conversely, invalid refill requests are stored on client 
computer 10 as invalid refill requests for manual or automated notification or report 
processing, as represented by box 394. Valid refill requests are used in a dispense 
transaction to dispense the prescription refill on host computer 14. After valid or invalid 
refill requests are stored, as represented by boxes 392 and 394, client computer 10 then 
determines, as represented by box 396, whether any additional stored requests exist. 

Automatic Validation Processing 
It is noted that when the operator has configured the software of client computer 10 
for on-line communications, as was discussed with reference to Figs. 3a and 3b, wherein the 
procedure is represented by boxes 200-296, the requests are stored on data storage 14 of 
client computer 10, represented by box 260. Referring now to Fig. 5b, box 460 also 
represents the storage of requests on client computer 10. However, box 460 represents that 
the requests are stored for validation processing when off-line detection has occurred, as 
shown in Fig. 5b. 

Referring now to Fig. 5a, in order to perform validation processing, on-line 
communications must be available. To place client computer 10 on-line, an operator issues 
the "host on command", represented by box 400. The operator preferably then executes the 
software of client computer 10, represented by box 406. The software of client computer 
10 has preferably been configured to perform validation processing and notification 



processing. Client computer 10 checks for incoming telephone calls and performs other 
tasks as represented by boxes 412 and 418. Such tasks include performing client computer 
validation processing, as represented by box 415, discussed below, or client computer 
notification processing as represented by box 515, also discussed below. Client computer 
10 answers incoming calls, represented by box 424, and gives the caller various options for 
services, represented by box 430, thereby continuing to collect specific request information 
from the patient such as patient identification, patient prescription number, or other 
information. Examples of various options for services include pharmacy hours of operation 
and location, information on medications, numbers to contact in case of questions, or an 
option to transfer to a live person. 

Client computer 10 determines whether the caller has ended the telephone call or 
made an invalid selection as represented by box 436. If so, client computer 10 ends the 
telephone call as represented by box 472. Otherwise, client computer 10 queries whether 
the caller wants to request a refill as represented by box 442. 

When client computer 10 is on-line with host computer 16 and a patient calls client 
computer 10 and requests a prescription refill, client computer 10 performs off-line detection 
by using a verification transaction, a software method, or by monitoring statuses rendered 
from other communications-related hardware devices, as represented by box 444. The 
verification transaction determines, as represented by box 445, whether interactive 
communications with host computer 16 are available to perform inquiries. 

If interactive communications with host computer 16 are not available at that 
moment, i.e., host computer 16 is off-line, then off-line communications processing is 



18 




initiated, represented by box 446. Once engaged in off-line communications processing, 
client computer 10 collects specific request information from the patient, represented by 
boxes 448 and 454 shown on Fig. 5b. The specific request information preferably consists 
of, but is not limited to: a variable length patient identification number, represented by box 
5 448; a variable length prescription number, represented by box 454; and, optionally, a 
variable length telephone number, credit card number or other information. Client 
computer 10 then stores the caller's request on local database 14, as represented by box 460, 
for validation processing when on-line communications with host computer 16 are restored. 
The caller is then informed of his or her unvalidated refill request status, as represented by 
\iLO box 462, with a message similar to, "if your request is valid, it will be filled". Finally, client 

^ computer 10 will query whether the caller has another refill request, as represented by box 

y. 

S B 466. If so, client computer 10 will then obtain a new prescription number from the client, 

3 as represented by box 454. Otherwise, client computer 10 ends the telephone call, as 

0 represented by box 472. 

a' 

sirs: 

^'^15 When on-line communications are re-established and client computer 10 conducts 

validation processing, the refill requests that are determined to be valid are stored for 
dispense processing, and the refill requests that are determined to be invalid are stored for 
notification processing, as discussed below. 

If client computer 10 determines, as represented by box 445 on Fig. 5a, that 
2 0 interactive communications with host computer 16 are available, then on-line 
communications processing is initiated, represented by box 476. Client computer 10 
functions according to the on-line configuration and thus expects interactive on-line 
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communications with host computer 16 to exist. Once engaged in on-line communications 
processing, client computer 10 collects specific request information from the patient, such 
as patient identification number, patient prescription number, or other information, 
represented by boxes 478 and 484 on Fig. 5b. Client computer 10 then validates the caller's 
5 request with the host computer, as represented by box 486. The caller is then informed of 
his or her validated refill status, as represented by box 487. Finally, client computer 10 
queries the caller as to whether the caller has another refill request, as represented by box 
496. If so, client computer 10 then obtains a new prescription number from the client, as 
represented by box 484. Otherwise, client computer 10 ends the telephone call, as 

^0 represented by box 472. 

M ■ ■ 

Now referring to Fig. 5c, when the operator has configured client computer 10 for 

CS 

C on-line communications with automatic validation processing, validation processing for client 

H : 

^ computer 10 is initiated, as represented by box 415. Client computer 10 performs off-line 

0 detection by using a verification transaction, a software method, or by monitoring statuses 

^^15 rendered from other communications-related hardware devices, as represented by box 488. 
^ The verification transaction determines, as represented by box 490, whether interactive 

communications with host computer 16 are available to perform inquiries. 

If on-line communications with host computer 16 are not available, i.e., host 
computer 16 is off-line, the client computer software processing is continued, as represented 
2 0 by box 410. 

If client computer 10 determines, as represented by box 490, that interactive 
communications with host computer 16 are available, then an inquiry transaction is initiated 
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from client computer 10 to host computer 16, to determine whether any unvalidated 
requests are stored in data storage 14, as represented by box 493. If no unvalidated requests 
exist, the client computer software processing is continued, as represented by box 410. 

If client computer 10 determines, as represented by box 492, that unvalidated 
5 requests are stored in data storage 14, then the unvalidated requests are retrieved and an 
inquiry transaction is initiated from client computer 10 to host computer 16, as represented 
by box 493. 

Client computer 10 then determines, represented by box 494, whether the client 

request is a valid request. A request that is validated by host computer 16 is stored on 
'^0 client computer 10 for dispense transaction processing as a valid pending refill request, 

represented by box 495. Conversely, invalidated refill requests are stored on client computer 
i2 10 as invalid refill requests for notification or report processing, as represented by box 497. 

= Valid refill requests are used in a dispense transaction to dispense the prescription refill on 

P host computer 14. Invalid refill requests are stored for notification processing, as discussed 

^^ 5 below. After invalid refill requests are stored, as represented by box 497, client computer 

10 then determines, as represented by box 492, whether any additional stored unvalidated 

requests exist. 

Notsfication Processing 

2 0 Once it is determined that the client computer 10 is not in communication with host 

computer 16 or the system is off-line, and requests for refills are received by client computer 
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10, the requests are stored for validation processing, as represented by boxes 160 of Fig. 1, 
260 of Fig. 3b, and 460 of Fig. 5b. 

Once on-line communication is re-established between client computer 10 and host 
computer 16, client computer 10 may then perform the validation processing task as 
represented by box 415 of Fig. 5a and shown in detail in Fig. 5c, boxes 415 through 497. 
At this point, the caller is unaware of whether his or her refill request has been determined 
to be valid or invalid. Therefore, in another embodiment of the invention, client computer 
10 performs notification processing as represented in box 515 of Fig. 5a and Fig. 5d. 

Notification processing may be a manual or automated process. Manual notification 
Ho processing is accomplished by using client computer 10 to produce a readable report that 
can be used by a technician for notifying the patients or any other business use. 

A human operator can issue a notify command that will cause client computer 10 to 
perform automated notification processing. Automated notification processing uses some 
or all of the existing telephone lines and attempts to contact all patients whose refill requests 
'4-5 are found to be invalid. The notify command initiates the process that determines whether 
any invalid refill requests exist. 

In the preferred embodiment, client computer 10 determines whether invalid refill 
requests exist. Client computer 10 then extracts the telephone number and status associated 
with the request and attempts to contact the patient. The automatic notification process 
2 0 only executes within specified hours. Therefore, calls are only placed during hours specified 
in this program, for example, during normal business hours or during home evening hours. 
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Client computer 10 attempts to call the patient on the telephone and inform the 
patient of the invalid refill status as determined during validation processing. In the event 
that a call is busy or unanswered, client computer 10 attempts another call at a later time 
until a defined period of time has elapsed or a total number of attempts has reached a 
5 defined limit. If the defined period of time or a total number of attempts has reached a 
defined limit, the invalid refill request status is stored for reporting as "not delivered". If 
a time period or predetermined retry count is reached, the invalid refill request status is 
stored for reporting as "not deliverable". If a telephone company situation information tone 
(SIT Tone) is received, then the invalid refill request is stored for reporting as 

O 

©LO "undeliverable". If the call is answered by an answering machine, methods known in the art 

y ■ 

^ are employed to attempt to leave a message stating the invalid status of the refill request. 

U 

I i If the message is successfully delivered then the invalid refill request status is stored for 

5 reporting as "delivered". Finally, if a call is answered by a patient, a message stating the 

\S invalid status of the refill request is given to the patient with an option to repeat the 

^^15 message or to transfer to a technician. Additionally, other appropriate options may be 

given. If the message is delivered, then an invalid request status is stored for reporting as 

"delivered". 

Whether the call was "not delivered," "delivered," or "undeliverable," the call 
disposition is stored. The call disposition reflects whether the call was busy, or if there was 
2 0 no answer, SIT tones, answering machine, a live patient, etc. 

In the preferred embodiment, software processes run by client computer 10 have 
components that may perform report processing. Some reports are automatically generated 



23 




and other reports may be generated as requested by an operator. A report may be 
produced in a computer readable format for use by another process or the report may be 
in a human readable form that could be used by a technician. 

5 Client Computer Configured for On-Line Communications with 

Automatic Notification Processing 

Referring now to Fig. 5d, client computer 10 first determines whether the current 

time is within allowable calling hours as represented by box 525. If not, client computer 10 

10 continues the software processing tasks as represented in box 410. If the current time is 

I within allowable calling hours, then client computer 10 determines whether any stored 

^ invalid refill requests exist, as represented by box 535. If not, then client computer 10 

continues software processing tasks as represented by box 410. 

If stored invalid refill requests do exist, then client computer 10 obtains an invalid 

3L5 refill request from local database 14. Client computer 10 then extracts the original 

y 

telephone number, original request time and vahdated status from the invalid request as 
^ represented in box 545. Client computer 10 then determines whether it is timely to deliver 

a notification message by assessing the elapsed time since a previous refill request was made, 
e.g., if a predetermined period of time has elapsed then no further notification messages will 
20 be issued. Client computer 10 preferably additionally determines whether a retry count is 
below an established limit, as represented by box 555. 

If it is determined that the notification message is untimely or a retry count is above 
an acceptable limit, then a message delivery counter is incremented and the refill request 
is assigned a "not deliverable" message status for report processing as represented by 595. 




If the notification message is determined to be timely and the retry count is below an 
acceptable limit as represented by box 555, then client computer 10 performs a notification 
telephone call function by attempting delivery of an invalid request message to the patient 
as represented by box 565. Examples of invalid request messages include: "This prescription 
is expired"; "This prescription is discontinued"; "It is too early to fill this prescription. Please 
call back after 'an appropriate date'"; "No refills are available"; "This prescription cannot be 
filled"; or other appropriate messages. The notification telephone call function is 
represented by box 565 and described in greater detail below, and is represented in greater 
detail by boxes 610 through 687 in Fig. 5e. Box 565 also appears as "enter" and "exit" boxes 
'^0 in Fig. 5e to illustrate that boxes 610 through 687 represent box 565 in greater detail. 

Referring back to Fig. 5d, the process for performing client computer notification 
processing is set forth. Client computer 10 then determines whether the notification 
message was delivered, as represented by box 575. 

If client computer 10 determines that the notification message was delivered, as 
Ilb represented by box 575, then client computer 10 increments a message delivery attempt 
counter and stores a delivered message status for report processing, as represented by box 
580. Client computer 10 then continues client computer software processing tasks as 
represented by box 410. 

If client computer 10 determines that the notification message is deliverable, as 
2 0 represented by box 585, then client computer 10 increments the message delivery attempt 
counter and stores "not delivered" message status for report processing and stores the invalid 
request for future retrieval by client computer 10 in future attempts at notification as 
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represented by box 590. Client computer 10 then continues software processing tasks as 
represented by box 410. 

If the notification message was determined by client computer 10 to have not been 
delivered, as represented by box 575, then client computer 10 determines whether the 
notification message was deliverable as represented by box 585. A preferred method of 
determining whether a message was deliverable is made by at least one of the series of tests 
represented by boxes 630 through 680 in Fig. 5e. If client computer 10 determines that the 
notification message is not deliverable, as represented by box 585, then client computer 10 
increments the message delivery counter and stores a "not deliverable" message status for 
report processing, as represented by box 595. 

The notification telephone call function and determination of whether a message is 
"deliverable", as represented by boxes 565, 575 and 585 in Fig. 5d, is shown in greater detail 
in Fig. 5e. To perform the notification telephone call function represented by box 565 in 
Fig. 5d, the client computer 10 first determines whether a telephone line is available as 
represented by box 610 in Fig. 5e. If a telephone line is determined to not be available, 
then client computer 10 determines that the notification message was "not delivered", as 
represented by box 617 in Fig. 5e. Call progress status, such as "not delivered" status, is 
assigned to the refill request. If client computer 10 determines that the telephone line is 
available, as represented by box 610, then client computer 10 dials the patient's telephone 
number as represented by box 620. Client computer 10 then determines whether the 
answering party is a human patient as represented by box 630. If the answering patient is 
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a human party, then the dient computer plays an "invahd refill request notification" message 
to the patient, as represented in box 633. 

In the preferred embodiment, client computer 10 allows the answering party to 
transfer to personnel, to repeat the message, or to engage other options, as represented by 
box 635. Client computer 10 then indicates that the message was delivered, as represented 
by box 637 and returns to the notification process as represented by "exit" box 565 in Fig, 
5e. 

If client computer 10 determines that a human patient has not answered the phone, 
as represented by box 630, client computer 10 then determines whether an electronic 
answering device has answered the phone, as known in the art, and represented by box 640. 
If it is determined that an electronic answering device has answered the phone, as 
represented by box 640, then client computer 10 plays an "invalid refill request" notification 
message to be recorded by the answering device as indicated by box 643. Client computer 
10 then indicates that the message was delivered as indicated by box 647 and returns to the 
notification process as indicated by box 565 in Fig. 5e. 

If client computer 10 determines that an electronic answering device has not 
answered the phone, as represented by box 640, then client computer 10 checks to 
determine if the line is busy as indicated by box 650. If it is determined that the line is 
busy, then client computer 10 indicates that the message was not delivered, as indicated in 
box 657. Client computer 10 then returns to the notification process, as indicated in box 565 
in Fig. 5e. 




If client computer 10 determines that there was no busy signal, as represented by box 
650, then client computer 10 checks to determine whether there is a ring with no answer, 
as represented by box 660. If it is determined by the test represented by box 660 that there 
is a ring and no answer, then client computer 10 indicates that the message was not 
5 delivered, as indicated by box 657, and returns to the notification process as represented in 
box 565 in Fig. 5e. 

If client computer 10 determines that it is not the case that there is a ring with no 
answer as indicated by box 660, then client computer 10 checks to determine whether there 
is no ring back as indicated in box 670. If there is no ring back, then client computer 10 

^0 indicates that the message was not delivered as represented by box 657 and returns to 

JS notification process as represented by box 565 in Fig. 5e. 

l,i If it is not the case that there is no ring back as indicated in box 670, then client 

5 computer 10 determines whether there is a situation information tone (SIT tone) as 

indicated in box 680. If there is a SIT tone, client computer 10 then indicates that the 
^3:5 message was undeliverable, as represented in box 687. Client computer 10 then returns the 
call progress status to the notification process as indicated by boxes 687 and 565 in Fig. 5e, 
Similarly, if there is no situation information tone, the message is still determined to be 
undeliverable since previous tests indicate that the message is undeliverable, as represented 
by boxes 630, 640, 650, 660 and 670. Therefore, client computer 10 determines that the 
2 0 message is undeliverable and returns the call progress status to a notification process as 
indicated in boxes 687 and 565 in Fig. 5e. 
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Client Computer Configured for On-Line or 
Off-Line Communications Using Manual Notification 

Referring now to Fig. 6a, an operator issues a NOTIFY command, as indicated by 

5 box 814. Client computer 10 then determines whether the current time is within allowable 

calling hours as represented by box 825. If not, client computer 10 continues the software 

processing tasks as represented in box 810. If the current time is within allowable calling 

hours, then client computer 10 determines whether any stored invalid refill requests exist, 

as represented by box 835. If not, then client computer 10 continues software processing 

10 tasks as represented by box 810. 

□ If stored invalid refill requests do exist, then client computer 10 obtains an invalid 

^ refill request from local database 14. Client computer 10 then extracts the original 

4i ' 

fl telephone number, original request time and validated status from the invalid request as 

lii represented in box 845. Client computer 10 then determines whether it is timely to deliver 

O- 5 a notification message by assessing the elapsed time since a previous refill request was made, 
e.g., if a predetermined period of time has elapsed, then no further notification message will 
^ be issued. Client computer 10 additionally determines whether a retry count is below an 

established limit, as represented by box 855. 

If it is determined that the notification message is untimely or a retry count is above 
20 an acceptable limit, then a message delivery counter is incremented and the refill request 
is assigned a "not deliverable" message status for report processing as represented by 895. 
If the notification message is determined to be timely and the retry count is below an 
acceptable limit as represented by box 855, then client computer 10 performs a notification 
telephone call function by attempting delivery of an invalid request message to the patient 
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as represented by box 865. The notification telephone call function represented by box 865 
and described in greater detail below, is represented in greater detail by boxes 910 through 
987 in Fig. 6b. Box 865 also appears as "enter" and "exit" boxes in Fig. 5e to illustrate that 
boxes 610 through 687 represent box 565 in greater detail. 

Referring back to Fig. 6a, the process for performing manual client computer 
notification processing is set forth. Client computer 10 then determines whether the 
notification message was delivered, as represented by box 875. 

If client computer 10 determines that the notification message was delivered, as 
represented by box 875, then client computer 10 increments a message delivery attempt 
counter and stores a delivered message status for report processing, as represented by box 
880. Client computer 10 then continues client computer software processing tasks as 
represented by box 810. 

If client computer 10 determines that the notification message is deliverable, as 
represented by box 885, then client computer 10 increments the message delivery attempt 
counter and stores "not delivered" message status for report processing and stores the invalid 
request for future retrieval by client computer 10 in future attempts at notification as 
represented by box 890. Client computer 10 then continues software processing tasks as 
represented by box 810. 

If the notification message was determined by client computer 10 to have not been 
delivered, as represented by box 875, then client computer 10 determines whether the 
notification message was deliverable as represented by box 885. A preferred method of 
determining whether a message was deliverable is made by at least one of the series of tests 
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represented by boxes 930 through 980 in Fig. 6b. If client computer 10 determines that the 
notification message is not deliverable, as represented by box 885, then client computer 10 
increments the message delivery counter and stores a "not deliverable" message status for 
report processing, as represented by box 895. 
5 Referring now to Fig. 6b, the notification telephone call function and determination 

of whether a message is "deliverable", as represented by boxes 865, 875 and 885 in Fig. 6a, 
is shown in greater detail. To perform the notification telephone call function represented 
by box 865 in Fig. 6a, the client computer 10 first determines whether a telephone line is 
available as represented by box 910, as shown in Fig. 6b. If a telephone line is determined 
to not be available, then client computer 10 determines that the notification message was 

y: 

^ "not delivered", as represented by box 917, as shown in Fig. 6b. Call progress status, such 

Li as "not delivered" status, is assigned to the refill request. If client computer 10 determines 

3 that the telephone line is available, as represented by box 910, then client computer 10 dials 

© the patient's telephone number as represented by box 920. Client computer 10 then 

^'%5 determines whether the answering party is a human patient as represented by box 930. If 

the answering party is a human party, then the client computer plays an "invalid refill 

request notification" message to the patient, as represented in box 933. 

In the preferred embodiment, client computer 10 allows the answering party to 

transfer to personnel, to repeat the message, or to engage other options, as represented by 
2 0 box 935. Client computer 10 then indicates that the message was delivered, as represented 

by box 937 and returns to the notification process as represented by box 865. 
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If client computer 10 detennines that a human patient has not answered the phone, 
as represented by box 930, client computer 10 then determines whether an electronic 
answering device has answered the phone, as known in the art, and represented by box 940. 
If it is determined that an electronic answering device has answered the phone, as 
5 represented by box 940, then client computer 10 plays an "invalid refill request" notification 
message to be recorded by the answering device as indicated by box 943. Client computer 
10 then indicates that the message was delivered as indicated by box 947 and returns to the 
notification process as indicated by box 865. 

If client computer 10 determines that an electronic answering device has not 

loirs' 

#0 answered the phone, as represented by box 940, then client computer 10 checks to 
^ determine if the line is busy as indicated by box 950. If it is determined that the line is 

l\l busy, then client computer 10 indicates that the message was not delivered, as indicated in 
- box 957. Client computer 10 then returns to the notification process, as indicated in "exit" 

s -5 

^ box 865 in Fig. 6b. 

"45 If client computer 10 determines that there was no busy signal, as represented by box 

\0 - 

™ 950, then client computer 10 checks to determine whether there is a ring with no answer, 

as represented by box 960. If it is determined by box 960 that there is a ring and no answer, 
then client computer 10 indicates that the message was not delivered, as indicated by box 
957, and returns to the notification process as represented in box 865 in Fig. 6b. 
2 0 If client computer 10 determines that it is not the case that there is a ring with no 

answer as indicated by box 960, then client computer 10 checks to determine whether there 
is no ring back as indicated in box 970. If there is no ring back, then client computer 10 
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indicates that the message was not delivered as represented by box 957 and returns to the 
notification process as represented by box 865 in Fig. 6b. 

If it is not the case that there is no ring back as indicated in box 970, then client 
computer 10 determines whether there is a situation information tone (SIT tone) as 
indicated in box 980. If there is a SIT tone, client computer 10 then indicates that the 
message was undeliverable, as represented in box 987. Client computer 10 then returns the 
call progress status to the notification process as indicated by boxes 987 and 865 in Fig. 6b. 
Similarly, if there is no situation information tone, the message is still determined to be 
undeliverable since previous tests indicate that the message is undeliverable, as represented 
by boxes 930, 940, 950, 960 and 970. Therefore, client computer 10 determines that the 
message is undeliverable and returns the call progress status to a notification process as 
indicated in boxes 987 and 865 in Fig. 6b. 

Whereas, the present invention has been described in relation to the drawings 
attached hereto, it should be understood that other and further modifications, apart from 
those shown or suggested herein, may be made within the spirit and scope of this invention. 



